home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000050_owner-urn-ietf _Wed Nov 6 00:16:15 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id AAA04904 for urn-ietf-out; Wed, 6 Nov 1996 00:16:15 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id AAA04899 for <urn-ietf@services.bunyip.com>; Wed, 6 Nov 1996 00:16:12 -0500
  3. Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA07927  (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 00:16:10 -0500
  5. Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <16211(7)>; Tue, 5 Nov 1996 21:16:06 PST
  6. Received: by golden.parc.xerox.com id <2696>; Tue, 5 Nov 1996 21:15:50 PST
  7. To: FisherM@is3.indy.tce.com
  8. Cc: rbriscoe@jungle.bt.co.uk, urn-ietf@bunyip.com
  9. In-Reply-To: <327F3294@MSMAIL.INDY.TCE.COM> (message from Fisher Mark on Tue,
  10.     5 Nov 1996 04:26:00 PST)
  11. Subject: Re: [URN] Persistence as part of URN framework
  12. From: Larry Masinter <masinter@parc.xerox.com>
  13. Message-Id: <96Nov5.211550pst."2696"@golden.parc.xerox.com>
  14. Date: Tue, 5 Nov 1996 21:15:50 PST
  15. Sender: owner-urn-ietf@services.bunyip.com
  16. Precedence: bulk
  17. Reply-To: Larry Masinter <masinter@parc.xerox.com>
  18. Errors-To: owner-urn-ietf@bunyip.com
  19.  
  20. # But there are no technical hooks to guarantee persistence.  On the 
  21. # cypherpunks list a few months ago, there was a discussion of what it would 
  22. # take to encrypt a message now, save it away for 100 years, then let the 
  23. # recipient decrypt the message.  The conclusion I drew from that discussion 
  24. # was that this was a hard problem without a technical solution short of 
  25. # deploying on every desktop and in every data center a persistent OS that 
  26. # stored copies of all persistent data.  Even then, the data would only 
  27. # persist as long as technical means remained to read the persistent data. 
  28. #  (How many of us could read a 600 bpi 9-track tape or punched card deck even 
  29. # if we had to?)
  30.  
  31. Jerry Saltzer & a grad student wrote some papers about long term
  32. document retention and the issues of system design for storage that
  33. was to last longer than 'mean time between site failure'. (Site
  34. failure = flood, earthquake, insurrection, war company bankruptcy,
  35. etc.)  Their system didn't require global replication, but it was
  36. important to be careful, and also not to be to complicated about your
  37. replication algorithms. Look for 'Library 2000' somewhere at
  38. www.lcs.mit.edu.
  39.  
  40. >From http://www.parc.xerox.com/masinter/www5stds.html:
  41.  
  42. > Some unsolved problems
  43. > - stuff goes away
  44. >   Material behind URLs disappears
  45. > - pimples.com
  46. >   vanity domains for billboard use
  47. > - Apple Computer and Apple Music
  48. >   conflicts over short names
  49. > - urn:hdl:MTV/I_quit
  50. >   how does authority migrate?
  51. > - http://www.mitro.paris.fr/mitro
  52. >   Non-ASCII names